Adds an ArrayBuffer-based invocation path for FFI functions whose
signatures are composed entirely of numeric types (i8..i64, u8..u64,
f32, f64, bool, char) and/or pointer types. The JS wrapper packs
arguments directly into a per-function AB via primordial DataView
setters and the C++ invoker (`InvokeFunctionSB`) reads them without
going through V8's `FunctionCallbackInfo`. Results are returned the same
way.

Pointer arguments use runtime dispatch: BigInt, null, and undefined take
the fast path, while Buffer, ArrayBuffer, ArrayBufferView, and String
fall back transparently to the classic `InvokeFunction` path via a
stashed `_invokeSlow` function. Signatures containing
non-numeric/non-pointer types also bypass the fast path.

The fast path is disabled on big-endian platforms.

Callers do not opt in, and the fast path is transparent in every way
users should rely on. One observable change: function wrappers returned
by `library.getFunction`, `library.getFunctions`, and `library.functions`
now have `.length` equal to the declared parameter count rather than
`0`. Code that relied on the previous value will need to be updated.

…tures

Raise JS coverage on `lib/internal/ffi-shared-buffer.js` from 83.14% to
99.84% so the nodejs/node `coverage-linux-without-intl` workflow's 95%
threshold is met (the workflow was failing at 94.98%).

Two kinds of changes:

* Mark genuinely-unreachable defensive blocks with `/* c8 ignore */`.
  These are `ERR_INTERNAL_ASSERTION` throws that trigger only when the
  native and JS sides disagree on the shared-buffer ABI, plus the
  `nargs === 0` branch in `buildNumericWrapper` which is dead today
  because `IsSBEligibleSignature` rejects 0-arg signatures on the
  native side.

* Add fixtures and tests to exercise every arity of the void-return
  specialization ladder (1, 3, 4, 5, plus the 7+ rest-params fallback;
  2 and 6 were already covered), and to hit the `throwFFIArgCountError`
  branch in each value-return specialization (1..6) and in the
  pointer-dispatch wrapper.

No behavior change in the FFI runtime path itself.

…r signatures